home *** CD-ROM | disk | FTP | other *** search
GNU Info File | 1995-06-16 | 41.6 KB | 953 lines |
- This is Info file gcc.info, produced by Makeinfo-1.55 from the input
- file gcc.texi.
-
- This file documents the use and the internals of the GNU compiler.
-
- Published by the Free Software Foundation 59 Temple Place - Suite 330
- Boston, MA 02111-1307 USA
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
- Foundation, Inc.
-
- Permission is granted to make and distribute verbatim copies of this
- manual provided the copyright notice and this permission notice are
- preserved on all copies.
-
- Permission is granted to copy and distribute modified versions of
- this manual under the conditions for verbatim copying, provided also
- that the sections entitled "GNU General Public License," "Funding for
- Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
- included exactly as in the original, and provided that the entire
- resulting derived work is distributed under the terms of a permission
- notice identical to this one.
-
- Permission is granted to copy and distribute translations of this
- manual into another language, under the above conditions for modified
- versions, except that the sections entitled "GNU General Public
- License," "Funding for Free Software," and "Protect Your Freedom--Fight
- `Look And Feel'", and this permission notice, may be included in
- translations approved by the Free Software Foundation instead of in the
- original English.
-
- File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble
-
- Cross-Compiler Problems
- =======================
-
- You may run into problems with cross compilation on certain machines,
- for several reasons.
-
- * Cross compilation can run into trouble for certain machines because
- some target machines' assemblers require floating point numbers to
- be written as *integer* constants in certain contexts.
-
- The compiler writes these integer constants by examining the
- floating point value as an integer and printing that integer,
- because this is simple to write and independent of the details of
- the floating point representation. But this does not work if the
- compiler is running on a different machine with an incompatible
- floating point format, or even a different byte-ordering.
-
- In addition, correct constant folding of floating point values
- requires representing them in the target machine's format. (The C
- standard does not quite require this, but in practice it is the
- only way to win.)
-
- It is now possible to overcome these problems by defining macros
- such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of
- work for each target machine. *Note Cross-compilation::.
-
- * At present, the program `mips-tfile' which adds debug support to
- object files on MIPS systems does not work in a cross compile
- environment.
-
- File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble
-
- Interoperation
- ==============
-
- This section lists various difficulties encountered in using GNU C or
- GNU C++ together with other compilers or with the assemblers, linkers,
- libraries and debuggers on certain systems.
-
- * Objective C does not work on the RS/6000.
-
- * GNU C++ does not do name mangling in the same way as other C++
- compilers. This means that object files compiled with one compiler
- cannot be used with another.
-
- This effect is intentional, to protect you from more subtle
- problems. Compilers differ as to many internal details of C++
- implementation, including: how class instances are laid out, how
- multiple inheritance is implemented, and how virtual function
- calls are handled. If the name encoding were made the same, your
- programs would link against libraries provided from other
- compilers--but the programs would then crash when run.
- Incompatible libraries are then detected at link time, rather than
- at run time.
-
- * Older GDB versions sometimes fail to read the output of GNU CC
- version 2. If you have trouble, get GDB version 4.4 or later.
-
- * DBX rejects some files produced by GNU CC, though it accepts
- similar constructs in output from PCC. Until someone can supply a
- coherent description of what is valid DBX input and what is not,
- there is nothing I can do about these problems. You are on your
- own.
-
- * The GNU assembler (GAS) does not support PIC. To generate PIC
- code, you must use some other assembler, such as `/bin/as'.
-
- * On some BSD systems, including some versions of Ultrix, use of
- profiling causes static variable destructors (currently used only
- in C++) not to be run.
-
- * Use of `-I/usr/include' may cause trouble.
-
- Many systems come with header files that won't work with GNU CC
- unless corrected by `fixincludes'. The corrected header files go
- in a new directory; GNU CC searches this directory before
- `/usr/include'. If you use `-I/usr/include', this tells GNU CC to
- search `/usr/include' earlier on, before the corrected headers.
- The result is that you get the uncorrected header files.
-
- Instead, you should use these options (when compiling C programs):
-
- -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include
-
- For C++ programs, GNU CC also uses a special directory that
- defines C++ interfaces to standard C subroutines. This directory
- is meant to be searched *before* other standard include
- directories, so that it takes precedence. If you are compiling
- C++ programs and specifying include directories explicitly, use
- this option first, then the two options above:
-
- -I/usr/local/lib/g++-include
-
- * On some SGI systems, when you use `-lgl_s' as an option, it gets
- translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this
- does not happen when you use GNU CC. You must specify all three
- options explicitly.
-
- * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte
- boundary, and it expects every `double' to be so aligned. The Sun
- compiler usually gives `double' values 8-byte alignment, with one
- exception: function arguments of type `double' may not be aligned.
-
- As a result, if a function compiled with Sun CC takes the address
- of an argument of type `double' and passes this pointer of type
- `double *' to a function compiled with GNU CC, dereferencing the
- pointer may cause a fatal signal.
-
- One way to solve this problem is to compile your entire program
- with GNU CC. Another solution is to modify the function that is
- compiled with Sun CC to copy the argument into a local variable;
- local variables are always properly aligned. A third solution is
- to modify the function that uses the pointer to dereference it via
- the following function `access_double' instead of directly with
- `*':
-
- inline double
- access_double (double *unaligned_ptr)
- {
- union d2i { double d; int i[2]; };
-
- union d2i *p = (union d2i *) unaligned_ptr;
- union d2i u;
-
- u.i[0] = p->i[0];
- u.i[1] = p->i[1];
-
- return u.d;
- }
-
- Storing into the pointer can be done likewise with the same union.
-
- * On Solaris, the `malloc' function in the `libmalloc.a' library may
- allocate memory that is only 4 byte aligned. Since GNU CC on the
- Sparc assumes that doubles are 8 byte aligned, this may result in a
- fatal signal if doubles are stored in memory allocated by the
- `libmalloc.a' library.
-
- The solution is to not use the `libmalloc.a' library. Use instead
- `malloc' and related functions from `libc.a'; they do not have
- this problem.
-
- * Sun forgot to include a static version of `libdl.a' with some
- versions of SunOS (mainly 4.1). This results in undefined symbols
- when linking static binaries (that is, if you use `-static'). If
- you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when
- linking, compile and link against the file `mit/util/misc/dlsym.c'
- from the MIT version of X windows.
-
- * The 128-bit long double format that the Sparc port supports
- currently works by using the architecturally defined quad-word
- floating point instructions. Since there is no hardware that
- supports these instructions they must be emulated by the operating
- system. Long doubles do not work in Sun OS versions 4.0.3 and
- earlier, because the kernel eumulator uses an obsolete and
- incompatible format. Long doubles do not work in Sun OS version
- 4.1.1 due to a problem in a Sun library. Long doubles do work on
- Sun OS versions 4.1.2 and higher, but GNU CC does not enable them
- by default. Long doubles appear to work in Sun OS 5.x (Solaris
- 2.x).
-
- * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not
- compile GNU CC correctly. We do not yet know why. However, GNU CC
- compiled on earlier HP-UX versions works properly on HP-UX 9.01
- and can compile itself properly on 9.01.
-
- * On the HP PA machine, ADB sometimes fails to work on functions
- compiled with GNU CC. Specifically, it fails to work on functions
- that use `alloca' or variable-size arrays. This is because GNU CC
- doesn't generate HP-UX unwind descriptors for such functions. It
- may even be impossible to generate them.
-
- * Debugging (`-g') is not supported on the HP PA machine, unless you
- use the preliminary GNU tools (*note Installation::.).
-
- * Taking the address of a label may generate errors from the HP-UX
- PA assembler. GAS for the PA does not have this problem.
-
- * Using floating point parameters for indirect calls to static
- functions will not work when using the HP assembler. There simply
- is no way for GCC to specify what registers hold arguments for
- static functions when using the HP assembler. GAS for the PA does
- not have this problem.
-
- * In extremely rare cases involvving some very large functions you
- may receive errors from the HP linker complaining about an out of
- bounds unconditional branch offset. This used to occur more often
- in previous versions of GNU CC, but is now exceptionally rare. If
- you should run into it, you can work around by making your
- function smaller.
-
- * GNU CC compiled code sometimes emits warnings from the HP-UX
- assembler of the form:
-
- (warning) Use of GR3 when
- frame >= 8192 may cause conflict.
-
- These warnings are harmless and can be safely ignored.
-
- * The current version of the assembler (`/bin/as') for the RS/6000
- has certain problems that prevent the `-g' option in GCC from
- working. Note that `Makefile.in' uses `-g' by default when
- compiling `libgcc2.c'.
-
- IBM has produced a fixed version of the assembler. The upgraded
- assembler unfortunately was not included in any of the AIX 3.2
- update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1
- should request PTF U403044 from IBM and users of AIX 3.2 should
- request PTF U416277. See the file `README.RS6000' for more
- details on these updates.
-
- You can test for the presense of a fixed assembler by using the
- command
-
- as -u < /dev/null
-
- If the command exits normally, the assembler fix already is
- installed. If the assembler complains that "-u" is an unknown
- flag, you need to order the fix.
-
- * On the IBM RS/6000, compiling code of the form
-
- extern int foo;
-
- ... foo ...
-
- static int foo;
-
- will cause the linker to report an undefined symbol `foo'.
- Although this behavior differs from most other systems, it is not a
- bug because redefining an `extern' variable as `static' is
- undefined in ANSI C.
-
- * AIX on the RS/6000 provides support (NLS) for environments outside
- of the United States. Compilers and assemblers use NLS to support
- locale-specific representations of various objects including
- floating-point numbers ("." vs "," for separating decimal
- fractions). There have been problems reported where the library
- linked with GCC does not produce the same floating-point formats
- that the assembler accepts. If you have this problem, set the
- LANG environment variable to "C" or "En_US".
-
- * Even if you specify `-fdollars-in-identifiers', you cannot
- successfully use `$' in identifiers on the RS/6000 due to a
- restriction in the IBM assembler. GAS supports these identifiers.
-
- * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC
- version 1.3.0.1 or later fixes this problem. You can obtain
- XLC-1.3.0.2 by requesting PTF 421749 from IBM.
-
- * There is an assembler bug in versions of DG/UX prior to 5.4.2.01
- that occurs when the `fldcr' instruction is used. GNU CC uses
- `fldcr' on the 88100 to serialize volatile memory references. Use
- the option `-mno-serialize-volatile' if your version of the
- assembler has this bug.
-
- * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
- messages from the linker. These warning messages complain of
- mismatched psect attributes. You can ignore them. *Note VMS
- Install::.
-
- * On NewsOS version 3, if you include both of the files `stddef.h'
- and `sys/types.h', you get an error because there are two typedefs
- of `size_t'. You should change `sys/types.h' by adding these
- lines around the definition of `size_t':
-
- #ifndef _SIZE_T
- #define _SIZE_T
- ACTUAL TYPEDEF HERE
- #endif
-
- * On the Alliant, the system's own convention for returning
- structures and unions is unusual, and is not compatible with GNU
- CC no matter what options are used.
-
- * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
- convention for structure and union returning. Use the option
- `-mhc-struct-return' to tell GNU CC to use a convention compatible
- with it.
-
- * On Ultrix, the Fortran compiler expects registers 2 through 5 to
- be saved by function calls. However, the C compiler uses
- conventions compatible with BSD Unix: registers 2 through 5 may be
- clobbered by function calls.
-
- GNU CC uses the same convention as the Ultrix C compiler. You can
- use these options to produce code compatible with the Fortran
- compiler:
-
- -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
-
- * On the WE32k, you may find that programs compiled with GNU CC do
- not work with the standard shared C library. You may need to link
- with the ordinary C compiler. If you do so, you must specify the
- following options:
-
- -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.7.0 -lgcc -lc_s
-
- The first specifies where to find the library `libgcc.a' specified
- with the `-lgcc' option.
-
- GNU CC does linking by invoking `ld', just as `cc' does, and there
- is no reason why it *should* matter which compilation program you
- use to invoke `ld'. If someone tracks this problem down, it can
- probably be fixed easily.
-
- * On the Alpha, you may get assembler errors about invalid syntax as
- a result of floating point constants. This is due to a bug in the
- C library functions `ecvt', `fcvt' and `gcvt'. Given valid
- floating point numbers, they sometimes print `NaN'.
-
- * On Irix 4.0.5F (and perhaps in some other versions), an assembler
- bug sometimes reorders instructions incorrectly when optimization
- is turned on. If you think this may be happening to you, try
- using the GNU assembler; GAS version 2.1 supports ECOFF on Irix.
-
- Or use the `-noasmopt' option when you compile GNU CC with itself,
- and then again when you compile your program. (This is a temporary
- kludge to turn off assembler optimization on Irix.) If this
- proves to be what you need, edit the assembler spec in the file
- `specs' so that it unconditionally passes `-O0' to the assembler,
- and never passes `-O2' or `-O3'.
-
- File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
-
- Problems Compiling Certain Programs
- ===================================
-
- Certain programs have problems compiling.
-
- * Parse errors may occur compiling X11 on a Decstation running
- Ultrix 4.2 because of problems in DEC's versions of the X11 header
- files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding
- `-I/usr/include/mit' to use the MIT versions of the header files,
- using the `-traditional' switch to turn off ANSI C, or fixing the
- header files by adding this:
-
- #ifdef __STDC__
- #define NeedFunctionPrototypes 0
- #endif
-
- * If you have trouble compiling Perl on a SunOS 4 system, it may be
- because Perl specifies `-I/usr/ucbinclude'. This accesses the
- unfixed header files. Perl specifies the options
-
- -traditional -Dvolatile=__volatile__
- -I/usr/include/sun -I/usr/ucbinclude
- -fpcc-struct-return
-
- most of which are unnecessary with GCC 2.4.5 and newer versions.
- You can make a properly working Perl by setting `ccflags' to
- `-fwritable-strings' (implied by the `-traditional' in the
- original options) and `cppflags' to empty in `config.sh', then
- typing `./doSH; make depend; make'.
-
- * On various 386 Unix systems derived from System V, including SCO,
- ISC, and ESIX, you may get error messages about running out of
- virtual memory while compiling certain programs.
-
- You can prevent this problem by linking GNU CC with the GNU malloc
- (which thus replaces the malloc that comes with the system). GNU
- malloc is available as a separate package, and also in the file
- `src/gmalloc.c' in the GNU Emacs 19 distribution.
-
- If you have installed GNU malloc as a separate library package,
- use this option when you relink GNU CC:
-
- MALLOC=/usr/local/lib/libgmalloc.a
-
- Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy
- the object file to `gmalloc.o' and use this option when you relink
- GNU CC:
-
- MALLOC=gmalloc.o
-
- File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble
-
- Incompatibilities of GNU CC
- ===========================
-
- There are several noteworthy incompatibilities between GNU C and most
- existing (non-ANSI) versions of C. The `-traditional' option
- eliminates many of these incompatibilities, *but not all*, by telling
- GNU C to behave like the other C compilers.
-
- * GNU CC normally makes string constants read-only. If several
- identical-looking string constants are used, GNU CC stores only one
- copy of the string.
-
- One consequence is that you cannot call `mktemp' with a string
- constant argument. The function `mktemp' always alters the string
- its argument points to.
-
- Another consequence is that `sscanf' does not work on some systems
- when passed a string constant as its format control string or
- input. This is because `sscanf' incorrectly tries to write into
- the string constant. Likewise `fscanf' and `scanf'.
-
- The best solution to these problems is to change the program to use
- `char'-array variables with initialization strings for these
- purposes instead of string constants. But if this is not possible,
- you can use the `-fwritable-strings' flag, which directs GNU CC to
- handle string constants the same way most C compilers do.
- `-traditional' also has this effect, among others.
-
- * `-2147483648' is positive.
-
- This is because 2147483648 cannot fit in the type `int', so
- (following the ANSI C rules) its data type is `unsigned long int'.
- Negating this value yields 2147483648 again.
-
- * GNU CC does not substitute macro arguments when they appear inside
- of string constants. For example, the following macro in GNU CC
-
- #define foo(a) "a"
-
- will produce output `"a"' regardless of what the argument A is.
-
- The `-traditional' option directs GNU CC to handle such cases
- (among others) in the old-fashioned (non-ANSI) fashion.
-
- * When you use `setjmp' and `longjmp', the only automatic variables
- guaranteed to remain valid are those declared `volatile'. This is
- a consequence of automatic register allocation. Consider this
- function:
-
- jmp_buf j;
-
- foo ()
- {
- int a, b;
-
- a = fun1 ();
- if (setjmp (j))
- return a;
-
- a = fun2 ();
- /* `longjmp (j)' may occur in `fun3'. */
- return a + fun3 ();
- }
-
- Here `a' may or may not be restored to its first value when the
- `longjmp' occurs. If `a' is allocated in a register, then its
- first value is restored; otherwise, it keeps the last value stored
- in it.
-
- If you use the `-W' option with the `-O' option, you will get a
- warning when GNU CC thinks such a problem might be possible.
-
- The `-traditional' option directs GNU C to put variables in the
- stack by default, rather than in registers, in functions that call
- `setjmp'. This results in the behavior found in traditional C
- compilers.
-
- * Programs that use preprocessing directives in the middle of macro
- arguments do not work with GNU CC. For example, a program like
- this will not work:
-
- foobar (
- #define luser
- hack)
-
- ANSI C does not permit such a construct. It would make sense to
- support it when `-traditional' is used, but it is too much work to
- implement.
-
- * Declarations of external variables and functions within a block
- apply only to the block containing the declaration. In other
- words, they have the same scope as any other declaration in the
- same place.
-
- In some other C compilers, a `extern' declaration affects all the
- rest of the file even if it happens within a block.
-
- The `-traditional' option directs GNU C to treat all `extern'
- declarations as global, like traditional compilers.
-
- * In traditional C, you can combine `long', etc., with a typedef
- name, as shown here:
-
- typedef int foo;
- typedef long foo bar;
-
- In ANSI C, this is not allowed: `long' and other type modifiers
- require an explicit `int'. Because this criterion is expressed by
- Bison grammar rules rather than C code, the `-traditional' flag
- cannot alter it.
-
- * PCC allows typedef names to be used as function parameters. The
- difficulty described immediately above applies here too.
-
- * PCC allows whitespace in the middle of compound assignment
- operators such as `+='. GNU CC, following the ANSI standard, does
- not allow this. The difficulty described immediately above
- applies here too.
-
- * GNU CC complains about unterminated character constants inside of
- preprocessing conditionals that fail. Some programs have English
- comments enclosed in conditionals that are guaranteed to fail; if
- these comments contain apostrophes, GNU CC will probably report an
- error. For example, this code would produce an error:
-
- #if 0
- You can't expect this to work.
- #endif
-
- The best solution to such a problem is to put the text into an
- actual C comment delimited by `/*...*/'. However, `-traditional'
- suppresses these error messages.
-
- * Many user programs contain the declaration `long time ();'. In the
- past, the system header files on many systems did not actually
- declare `time', so it did not matter what type your program
- declared it to return. But in systems with ANSI C headers, `time'
- is declared to return `time_t', and if that is not the same as
- `long', then `long time ();' is erroneous.
-
- The solution is to change your program to use `time_t' as the
- return type of `time'.
-
- * When compiling functions that return `float', PCC converts it to a
- double. GNU CC actually returns a `float'. If you are concerned
- with PCC compatibility, you should declare your functions to return
- `double'; you might as well say what you mean.
-
- * When compiling functions that return structures or unions, GNU CC
- output code normally uses a method different from that used on most
- versions of Unix. As a result, code compiled with GNU CC cannot
- call a structure-returning function compiled with PCC, and vice
- versa.
-
- The method used by GNU CC is as follows: a structure or union
- which is 1, 2, 4 or 8 bytes long is returned like a scalar. A
- structure or union with any other size is stored into an address
- supplied by the caller (usually in a special, fixed register, but
- on some machines it is passed on the stack). The
- machine-description macros `STRUCT_VALUE' and
- `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address.
-
- By contrast, PCC on most target machines returns structures and
- unions of any size by copying the data into an area of static
- storage, and then returning the address of that storage as if it
- were a pointer value. The caller must copy the data from that
- memory area to the place where the value is wanted. GNU CC does
- not use this method because it is slower and nonreentrant.
-
- On some newer machines, PCC uses a reentrant convention for all
- structure and union returning. GNU CC on most of these machines
- uses a compatible convention when returning structures and unions
- in memory, but still returns small structures and unions in
- registers.
-
- You can tell GNU CC to use a compatible convention for all
- structure and union returning with the option
- `-fpcc-struct-return'.
-
- * GNU C complains about program fragments such as `0x74ae-0x4000'
- which appear to be two hexadecimal constants separated by the minus
- operator. Actually, this string is a single "preprocessing token".
- Each such token must correspond to one token in C. Since this
- does not, GNU C prints an error message. Although it may appear
- obvious that what is meant is an operator and two values, the ANSI
- C standard specifically requires that this be treated as erroneous.
-
- A "preprocessing token" is a "preprocessing number" if it begins
- with a digit and is followed by letters, underscores, digits,
- periods and `e+', `e-', `E+', or `E-' character sequences.
-
- To make the above program fragment valid, place whitespace in
- front of the minus sign. This whitespace will end the
- preprocessing number.
-
- File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
-
- Fixed Header Files
- ==================
-
- GNU CC needs to install corrected versions of some system header
- files. This is because most target systems have some header files that
- won't work with GNU CC unless they are changed. Some have bugs, some
- are incompatible with ANSI C, and some depend on special features of
- other compilers.
-
- Installing GNU CC automatically creates and installs the fixed header
- files, by running a program called `fixincludes' (or for certain
- targets an alternative such as `fixinc.svr4'). Normally, you don't
- need to pay attention to this. But there are cases where it doesn't do
- the right thing automatically.
-
- * If you update the system's header files, such as by installing a
- new system version, the fixed header files of GNU CC are not
- automatically updated. The easiest way to update them is to
- reinstall GNU CC. (If you want to be clever, look in the makefile
- and you can find a shortcut.)
-
- * On some systems, in particular SunOS 4, header file directories
- contain machine-specific symbolic links in certain places. This
- makes it possible to share most of the header files among hosts
- running the same version of SunOS 4 on different machine models.
-
- The programs that fix the header files do not understand this
- special way of using symbolic links; therefore, the directory of
- fixed header files is good only for the machine model used to
- build it.
-
- In SunOS 4, only programs that look inside the kernel will notice
- the difference between machine models. Therefore, for most
- purposes, you need not be concerned about this.
-
- It is possible to make separate sets of fixed header files for the
- different machine models, and arrange a structure of symbolic
- links so as to use the proper set, but you'll have to do this by
- hand.
-
- * On Lynxos, GNU CC by default does not fix the header files. This
- is because bugs in the shell cause the `fixincludes' script to
- fail.
-
- This means you will encounter problems due to bugs in the system
- header files. It may be no comfort that they aren't GNU CC's
- fault, but it does mean that there's nothing for us to do about
- them.
-
- File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble
-
- Standard Libraries
- ==================
-
- GNU CC by itself attempts to be what the ISO/ANSI C standard calls a
- "conforming freestanding implementation". This means all ANSI C
- language features are available, as well as the contents of `float.h',
- `limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is
- supplied by the vendor of the operating system. If that C library
- doesn't conform to the C standards, then your programs might get
- warnings (especially when using `-Wall') that you don't expect.
-
- For example, the `sprintf' function on SunOS 4.1.3 returns `char *'
- while the C standard says that `sprintf' returns an `int'. The
- `fixincludes' program could make the prototype for this function match
- the Standard, but that would be wrong, since the function will still
- return `char *'.
-
- If you need a Standard compliant library, then you need to find one,
- as GNU CC does not provide one. The GNU C library (called `glibc') has
- been ported to a number of operating systems, and provides ANSI/ISO,
- POSIX, BSD and SystemV compatibility. You could also ask your operating
- system vendor if newer libraries are available.
-
- File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble
-
- Disappointments and Misunderstandings
- =====================================
-
- These problems are perhaps regrettable, but we don't know any
- practical way around them.
-
- * Certain local variables aren't recognized by debuggers when you
- compile with optimization.
-
- This occurs because sometimes GNU CC optimizes the variable out of
- existence. There is no way to tell the debugger how to compute the
- value such a variable "would have had", and it is not clear that
- would be desirable anyway. So GNU CC simply does not mention the
- eliminated variable when it writes debugging information.
-
- You have to expect a certain amount of disagreement between the
- executable and your source code, when you use optimization.
-
- * Users often think it is a bug when GNU CC reports an error for code
- like this:
-
- int foo (struct mumble *);
-
- struct mumble { ... };
-
- int foo (struct mumble *x)
- { ... }
-
- This code really is erroneous, because the scope of `struct
- mumble' in the prototype is limited to the argument list
- containing it. It does not refer to the `struct mumble' defined
- with file scope immediately below--they are two unrelated types
- with similar names in different scopes.
-
- But in the definition of `foo', the file-scope type is used
- because that is available to be inherited. Thus, the definition
- and the prototype do not match, and you get an error.
-
- This behavior may seem silly, but it's what the ANSI standard
- specifies. It is easy enough for you to make your code work by
- moving the definition of `struct mumble' above the prototype.
- It's not worth being incompatible with ANSI C just to avoid an
- error for the example shown above.
-
- * Accesses to bitfields even in volatile objects works by accessing
- larger objects, such as a byte or a word. You cannot rely on what
- size of object is accessed in order to read or write the bitfield;
- it may even vary for a given bitfield according to the precise
- usage.
-
- If you care about controlling the amount of memory that is
- accessed, use volatile but do not use bitfields.
-
- * GNU CC comes with shell scripts to fix certain known problems in
- system header files. They install corrected copies of various
- header files in a special directory where only GNU CC will
- normally look for them. The scripts adapt to various systems by
- searching all the system header files for the problem cases that
- we know about.
-
- If new system header files are installed, nothing automatically
- arranges to update the corrected header files. You will have to
- reinstall GNU CC to fix the new header files. More specifically,
- go to the build directory and delete the files `stmp-fixinc' and
- `stmp-headers', and the subdirectory `include'; then do `make
- install' again.
-
- * On 68000 systems, you can get paradoxical results if you test the
- precise values of floating point numbers. For example, you can
- find that a floating point value which is not a NaN is not equal
- to itself. This results from the fact that the the floating point
- registers hold a few more bits of precision than fit in a `double'
- in memory. Compiled code moves values between memory and floating
- point registers at its convenience, and moving them into memory
- truncates them.
-
- You can partially avoid this problem by using the `-ffloat-store'
- option (*note Optimize Options::.).
-
- * On the MIPS, variable argument functions using `varargs.h' cannot
- have a floating point value for the first argument. The reason
- for this is that in the absence of a prototype in scope, if the
- first argument is a floating point, it is passed in a floating
- point register, rather than an integer register.
-
- If the code is rewritten to use the ANSI standard `stdarg.h'
- method of variable arguments, and the prototype is in scope at the
- time of the call, everything will work fine.
-
- File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble
-
- Common Misunderstandings with GNU C++
- =====================================
-
- C++ is a complex language and an evolving one, and its standard
- definition (the ANSI C++ draft standard) is also evolving. As a result,
- your C++ compiler may occasionally surprise you, even when its behavior
- is correct. This section discusses some areas that frequently give
- rise to questions of this sort.
-
- * Menu:
-
- * Static Definitions:: Static member declarations are not definitions
- * Temporaries:: Temporaries may vanish before you expect
-
- File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings
-
- Declare *and* Define Static Members
- -----------------------------------
-
- When a class has static data members, it is not enough to *declare*
- the static member; you must also *define* it. For example:
-
- class Foo
- {
- ...
- void method();
- static int bar;
- };
-
- This declaration only establishes that the class `Foo' has an `int'
- named `Foo::bar', and a member function named `Foo::method'. But you
- still need to define *both* `method' and `bar' elsewhere. According to
- the draft ANSI standard, you must supply an initializer in one (and
- only one) source file, such as:
-
- int Foo::bar = 0;
-
- Other C++ compilers may not correctly implement the standard
- behavior. As a result, when you switch to `g++' from one of these
- compilers, you may discover that a program that appeared to work
- correctly in fact does not conform to the standard: `g++' reports as
- undefined symbols any static data members that lack definitions.
-
- File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings
-
- Temporaries May Vanish Before You Expect
- ----------------------------------------
-
- It is dangerous to use pointers or references to *portions* of a
- temporary object. The compiler may very well delete the object before
- you expect it to, leaving a pointer to garbage. The most common place
- where this problem crops up is in classes like the libg++ `String'
- class, that define a conversion function to type `char *' or `const
- char *'. However, any class that returns a pointer to some internal
- structure is potentially subject to this problem.
-
- For example, a program may use a function `strfunc' that returns
- `String' objects, and another function `charfunc' that operates on
- pointers to `char':
-
- String strfunc ();
- void charfunc (const char *);
-
- In this situation, it may seem natural to write
- `charfunc (strfunc ());' based on the knowledge that class `String' has
- an explicit conversion to `char' pointers. However, what really
- happens is akin to `charfunc (strfunc ().convert ());', where the
- `convert' method is a function to do the same data conversion normally
- performed by a cast. Since the last use of the temporary `String'
- object is the call to the conversion function, the compiler may delete
- that object before actually calling `charfunc'. The compiler has no
- way of knowing that deleting the `String' object will invalidate the
- pointer. The pointer then points to garbage, so that by the time
- `charfunc' is called, it gets an invalid argument.
-
- Code like this may run successfully under some other compilers,
- especially those that delete temporaries relatively late. However, the
- GNU C++ behavior is also standard-conformant, so if your program depends
- on late destruction of temporaries it is not portable.
-
- If you think this is surprising, you should be aware that the ANSI
- C++ committee continues to debate the lifetime-of-temporaries problem.
-
- For now, at least, the safe way to write such code is to give the
- temporary a name, which forces it to remain until the end of the scope
- of the name. For example:
-
- String& tmp = strfunc ();
- charfunc (tmp);
-
- File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble
-
- Caveats of using `protoize'
- ===========================
-
- The conversion programs `protoize' and `unprotoize' can sometimes
- change a source file in a way that won't work unless you rearrange it.
-
- * `protoize' can insert references to a type name or type tag before
- the definition, or in a file where they are not defined.
-
- If this happens, compiler error messages should show you where the
- new references are, so fixing the file by hand is straightforward.
-
- * There are some C constructs which `protoize' cannot figure out.
- For example, it can't determine argument types for declaring a
- pointer-to-function variable; this you must do by hand. `protoize'
- inserts a comment containing `???' each time it finds such a
- variable; so you can find all such variables by searching for this
- string. ANSI C does not require declaring the argument types of
- pointer-to-function types.
-
- * Using `unprotoize' can easily introduce bugs. If the program
- relied on prototypes to bring about conversion of arguments, these
- conversions will not take place in the program without prototypes.
- One case in which you can be sure `unprotoize' is safe is when you
- are removing prototypes that were made with `protoize'; if the
- program worked before without any prototypes, it will work again
- without them.
-
- You can find all the places where this problem might occur by
- compiling the program with the `-Wconversion' option. It prints a
- warning whenever an argument is converted.
-
- * Both conversion programs can be confused if there are macro calls
- in and around the text to be converted. In other words, the
- standard syntax for a declaration or definition must not result
- from expanding a macro. This problem is inherent in the design of
- C and cannot be fixed. If only a few functions have confusing
- macro calls, you can easily convert them manually.
-
- * `protoize' cannot get the argument types for a function whose
- definition was not actually compiled due to preprocessing
- conditionals. When this happens, `protoize' changes nothing in
- regard to such a function. `protoize' tries to detect such
- instances and warn about them.
-
- You can generally work around this problem by using `protoize' step
- by step, each time specifying a different set of `-D' options for
- compilation, until all of the functions have been converted.
- There is no automatic way to verify that you have got them all,
- however.
-
- * Confusion may result if there is an occasion to convert a function
- declaration or definition in a region of source code where there
- is more than one formal parameter list present. Thus, attempts to
- convert code containing multiple (conditionally compiled) versions
- of a single function header (in the same vicinity) may not produce
- the desired (or expected) results.
-
- If you plan on converting source files which contain such code, it
- is recommended that you first make sure that each conditionally
- compiled region of source code which contains an alternative
- function header also contains at least one additional follower
- token (past the final right parenthesis of the function header).
- This should circumvent the problem.
-
- * `unprotoize' can become confused when trying to convert a function
- definition or declaration which contains a declaration for a
- pointer-to-function formal argument which has the same name as the
- function being defined or declared. We recommand you avoid such
- choices of formal parameter names.
-
- * You might also want to correct some of the indentation by hand and
- break long lines. (The conversion programs don't write lines
- longer than eighty characters in any case.)
-
-